Automated transaction engine

ABSTRACT

Various embodiments of the present technology generally relate to automated tools for tracking, recording, restoring and auditing transactions. In accordance with various embodiments, applications and servers can provide a variety of features including, but not limited to, behind the scene monitoring activity (transaction or business) and recording, persisting client activity, ubiquitous autosave, business workflow and approval lifecycles, error correction at the business level, management of the state of the transaction without the user having to manage the activity, tracking posted and unposted transactions (e.g., business state), and the like. The applications can communicate with a unified transaction engine that combines awareness of database transaction state along with business transaction states. As a result, the end-user and/or developer do not have to be concerned about the underlying differences between the database transaction state and business transaction states, and can focus on where their transaction is in its lifecycle.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. application Ser. No. 15/949,397filed Apr. 10, 2018, now allowed; which claims priority to U.S.Provisional Application Ser. No. 62/597,237 filed Dec. 11, 2017, all ofwhich are incorporated herein by reference in its entirety for allpurposes.

BACKGROUND

Modern electronic devices such as computers, tablets, mobile phones,wearable devices and the like have become a common part of modern life.Many users of electronic devices routinely utilize various types ofsoftware applications for business and personal activities. Manybusiness use customized software to assist users in creating customizedtransactions (e.g., creating a customized parts list), managing orders,ensuring workflows are followed, tracking shipments, and the like. Thesesoftware applications can also be used to perform specific calculations,produce charts, organize data, and the like. Moreover, there are avariety of channels for delivering software and services to end-usersincluding cloud computing services software as a service (SaaS),platform as a service (PaaS), and the like.

The software applications can create various transactional entrieswithin databases. Many traditional systems seek to ensure that atransaction will comply with an ACID (Atomicity, Consistency, Isolation,and Durability) transaction model. Atomicity requires that eachtransaction be captured as an atomic unit (e.g., the transaction iswholly captured, or nothing is capture at all) even in view of systemfailures and power outages. Accordingly, a database entry is leftunmodified if any part of the transaction fails for any reason.Consistency means that any transaction results in a transition from onevalid state to another within the database. Concurrent execution oftransactions results in a system state that would be obtained iftransactions were executed sequentially (e.g., one after the other) isensured by isolation. Finally, durability ensures that once atransaction has been committed, the transaction will remain even in theevent of power loss, crashes, or errors. For example, once a group ofSQL statements execute, the results need to be stored permanently evenif the database crashes.

Unfortunately, these traditional systems often process data in a waythat creates server affinity. Moreover, these traditional systemstypically create large sets of disjoint transactions that are reallypart of a single business flow. For example, creation of a customizedparts list may be considered as one transaction while order fulfillmentmay be considered completely separately. In addition, users of thesoftware application often have to perform specific actions in order fora current state of the transaction to be persisted to the database. As aresult, when various system failures occur, there is a potential loss ofwork if the user has not recently requested the data be saved.

SUMMARY

Various embodiments of the present technology generally relate toautomated tools for tracking, recording, restoring, and auditingtransactions. Some embodiments provide for an automated transactionsystem that is always on capturing activity on client devices. Theautomated transaction system can have one or more processors, a memory,communications component, a transaction engine, a database, an auditengine, and/or a metadata-driven boundary detector. The communicationscomponent can be configured to receive activity snapshots identifyingchanges to a transactional entry being modified in an applicationrunning on a client device. The activity snapshots can be automaticallycreated in response to triggering events (e.g., expiration of timers,reaching logical transaction boundaries, detection of metadata definedtrigger points, crossing of metadata boundaries such as a screen change,or the like). In some embodiments, the activity snapshots may onlyidentify changes to the transactional entry since a previous activitysnapshot. The activity snapshots can be a series of transient recordsrepresenting a series of changes to the transactional entry to returnthe transactional entry from a current state to a previous state.

The transaction engine can be configured to create transient recordsthat link the activity snapshots received from the client device to atransaction. In some embodiments, the transaction engine can usebusiness logic to associate a workflow state to each of the activitysnapshots. The transaction engine can also assign transactionidentifiers to each of the activity snapshots. The database can storethe transient records and any traditional transaction records. The auditengine can be configured to access the transient records stored in thedatabase and create, based on the business logic, an audit trailidentifying workflow activity. The metadata-driven boundary detector cananalyze the transient records for a boundary identified by the businesslogic and create a persistent record within the database. In someembodiments, the metadata-driven boundary detector can create thepersistent record based on the transient records and then remove thetransient records from the database.

Embodiments of the present invention also include computer-readablestorage media containing sets of instructions to cause one or moreprocessors to perform the methods, variations of the methods, and otheroperations described herein.

Some embodiments include a method that comprises receiving, from anapplication running on a client device, activity snapshots identifyingchanges to a transaction being modified in the application. The activitysnapshots can be automatically created in response to triggering eventsaccording to various embodiments. The activity snapshots may identifyonly the changes to the transaction that have occurred since a previousactivity snapshot and may also include client session information, zoneinformation, time stamps, user identifiers, and the like. In someembodiments, the activity snapshots can be linked to an automatedtransaction record. The linking of the activity snapshots to theautomated transaction record may include assigning a transactionidentifier to the activity snapshots.

In some embodiments, a request to restore the transaction to a previousstate can be received. The request to restore the transaction to theprevious state can automatically generated upon detection of a failurewithin the system that could have resulted in a loss of data. Inresponse to receiving the request to restore, the activity snapshotsassociated with the automated transaction record can be processed tocreate the previous state of the transaction. Some embodiments processthe activity snapshots by identifying a subset of transactional datathat will return the automated transaction record to the previous stateand then transmitting from a server to the client device, the subset ofthe transactional data to the application. Some data may be combined orremoved based on the processing.

While multiple embodiments are disclosed, still other embodiments of thepresent invention will become apparent to those skilled in the art fromthe following detailed description, which shows and describesillustrative embodiments of the invention. As will be realized, theinvention is capable of modifications in various aspects, all withoutdeparting from the scope of the present invention. Accordingly, thedrawings and detailed description are to be regarded as illustrative innature and not restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present technology will be described and explainedthrough the use of the accompanying drawings in which:

FIG. 1 illustrates an example of an operating environment in which someembodiments of the present technology may be utilized;

FIG. 2 illustrates a set of components that may be used to createautomated transaction records according to one or more embodiments ofthe present technology;

FIG. 3 illustrates logical components of an automated transaction engineaccording to various embodiments of the present technology;

FIG. 4 is a flowchart illustrating a set of operations for restoring atransaction record according to one or more embodiments of the presenttechnology;

FIG. 5 is a flowchart illustrating a set of operations for creating anaudit record according to one or more embodiments of the presenttechnology;

FIG. 6 is a sequence diagram illustrating an example of communicationsbetween various components of a system with an automated transactionengine according to various embodiments of the present technology; and

FIG. 7 illustrates an example of a computing system, which isrepresentative of any system or collection of systems in which thevarious applications, services, scenarios, and processes disclosedherein may be implemented.

The drawings have not necessarily been drawn to scale. Similarly, somecomponents and/or operations may be separated into different blocks orcombined into a single block for the purposes of discussion of some ofthe embodiments of the present technology. Moreover, while thetechnology is amenable to various modifications and alternative forms,specific embodiments have been shown by way of example in the drawingsand are described in detail below. The intention, however, is not tolimit the technology to the particular embodiments described. On thecontrary, the technology is intended to cover all modifications,equivalents, and alternatives falling within the scope of the technologyas defined by the appended claims.

DETAILED DESCRIPTION

Various embodiments of the present technology generally relate toautomated tools for tracking, recording, restoring, and auditingtransactions. Traditional systems often use a click and save model torecord transactions. As such, work can easily be lost if a user has notperformed a specific action requesting a save of activity within anapplication. In contrast, various embodiments of the present technologyautomatically record all (or substantially all) activity from a firstkey stroke of a transaction all the way until the transaction is dead(e.g., sales order has been shipped and paid). Moreover, instead ofrecording events within the transaction as separate sets of disjointtransactions (e.g., transaction creation, order fulfillment, ordershipment, etc.), various embodiments use business logic to identifytransaction boundaries and effectively create a single transaction withmultiple states.

Various embodiments of the present technology encompass more thantraditional transactions and includes additional characteristics such asworkflow, audit, client session management, transient work, and othercharacteristics. As a result, from a first key click or firstinteraction, if a part of the system fails, any information about thecurrent state is recorded resulting in a system that is lossless,stateless, scalable (e.g., horizontally scalable), multistate (e.g.,business state, contextual state, etc.), auditable (e.g., contextualaudit), and the like.

Various embodiments of the present technology provide for a wide rangeof technical effects, advantages, and/or improvements to computingsystems, components, and applications. For example, various embodimentsinclude one or more of the following technical effects, advantages,and/or improvements: 1) provide unique tools that link all activitywithin a transaction boundary; 2) creation of a unique signalingprotocol between a client device and server to automatically recordsession activity; 3) utilization of transient activity records thatidentify successive changes within a client session to a serverresulting in a reduction of server memory; 4) system interactionsallowing any server to instantly pick up a client session (i.e., noserver affinity); 5) use unconventional and non-routine operations aspart of creating, updating, and monitoring custom software applications;6) unique systems and methods that allow behind the scene monitoring andrecoding of activity (e.g., transactional activity or businessactivity); 7) persisting of client activity; 8) ubiquitous auto save; 9)management of business workflow lifecycles; 9) managing the state of thetransaction without the user having to manage the activity; and/or 10)transaction auditing. Some embodiments include additional technicaleffects, advantages, and/or improvements to computing systems andcomponents.

In the following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of embodiments of the present technology. It will beapparent, however, to one skilled in the art that embodiments of thepresent technology may be practiced without some of these specificdetails. While, for convenience, embodiments of the present technologyare described with reference to various computing architectures,embodiments of the present technology are equally applicable to variousother cloud-based and distributed processing techniques.

The techniques introduced here can be embodied as special-purposehardware (e.g., circuitry), as programmable circuitry appropriatelyprogrammed with software and/or firmware, or as a combination ofspecial-purpose and programmable circuitry. Hence, embodiments mayinclude a machine-readable medium having stored thereon instructionswhich may be used to program a computer (or other electronic devices) toperform a process. The machine-readable medium may include, but is notlimited to, optical disks, compact disc read-only memories (CD-ROMs),magneto-optical disks, ROMs, random access memories (RAMs), erasableprogrammable read-only memories (EPROMs), electrically erasableprogrammable read-only memories (EEPROMs), magnetic or optical cards,flash memory, or other type of media/machine-readable medium suitablefor storing electronic instructions.

The phrases “in some embodiments,” “according to some embodiments,” “inthe embodiments shown,” “in other embodiments,” and the like generallymean the particular feature, structure, or characteristic following thephrase is included in at least one implementation of the presenttechnology, and may be included in more than one implementation. Inaddition, such phrases do not necessarily refer to the same embodimentsor different embodiments.

FIG. 1 illustrates an example of an operating environment 100 in whichsome embodiments of the present technology may be utilized. Asillustrated in FIG. 1, operating environment 100 may include one or moreapplications running on client devices 110A-110N (e.g., a mobile phone,tablet computer, mobile media device, mobile gaming device,vehicle-based computer, wearable computing device, etc.), network 120,load balancers 130, servers 140A-140N, and transaction databases 150having entries 160 created in response to transaction 170A-170N.Applications accessed via client devices 110A-110N can be large scaleenterprise application capable of performing large scale complextransactions in a stateless manner. As such, these large scale complextransactions can be instantly handed off and/or picked up by anotherserver for any reason (e.g., load balancing, server failures, etc.).

In accordance with various embodiments, client devices 110A-110N caninclude a variety of network communication components that enable clientdevices 110A-110N to communicate with remote servers 140A-140N or otherportable electronic devices by transmitting and receiving wirelesssignals using licensed, semi-licensed or unlicensed spectrum over acommunications network. In some cases, the communications network may becomprised of multiple networks, even multiple heterogeneous networks,such as one or more border networks, voice networks, broadband networks,service provider networks, Internet Service Provider (ISP) networks,and/or Public Switched Telephone Networks (PSTNs), interconnected viagateways operable to facilitate communications between and among thevarious networks. In accordance with various embodiments, load balancers130 can run in a stateless mode so that any client session or clientdevice has no affinity to a particular server 140A-140N. This lack ofserver affinity is the result, at least in part, of the unique signalingprotocol between client devices 110A-110N and remote servers 140A-140Nused in various embodiments to automatically record session activity.

Servers 140A-140N can host applications which can be accessed via clientdevices 110A-110N. In accordance with various embodiments, theseapplications and servers can provide a variety of features including,but not limited to, behind the scene monitoring activity (transaction orbusiness) and recording, persisting client activity, ubiquitousautosave, business workflow and approval lifecycles, error correction atthe business level, management of the state of the transaction withoutthe user having to manage the activity, tracking posted and unpostedtransactions (e.g., business state), and the like. The applications cancommunicate with a unified transaction engine that combines awareness ofdatabase transaction state along with business transaction states. As aresult, the end-user and/or developer do not have to be concerned aboutthe underlying differences between the database transaction state andbusiness transaction states, and can focus on where their transaction isin its lifecycle. As users interact with the application, the system canmonitor, track, and/or record the states and other transactional data intransaction database 150.

Various embodiments of the present technology allow changes totransactions 160A-160B to be identified and sent in repeated multiplesmall snapshots. As a result of sending the changes more frequently to aserver 140A-140N, the server memory can be reduced and any server canimmediately pick up the activity (i.e., there is no server affinity).The small snapshots of the changes or transient activity can be sentupon triggering events (e.g., time, metadata boundary detection, screenchange, logical transaction boundary, and change detection). Forexample, as a user changes from one screen to another (e.g., a usercrosses metadata boundary), a snapshot may be captured. In addition, insome embodiments, the snapshots may be capture without any user-basedtriggers. For example, snapshots may be captured asynchronously in thebackground can be tracked and recorded and ultimately recovered ifneeded.

In some embodiments, the snapshots may include more than just the dataand changes to the data but may also capture information about how thedata is being presented. For example, is the data being presented incolumn format or table for sorting. Similarly, addition characteristicsabout the user interface can be captured by the snapshots and ultimatelyrestored. For example, the current state of the tabs (e.g., placement,expanded, not expanded, color preferences, window placement,configurations, etc.) can be captured. As a result, user activity can betracked without any explicit event and ubiquitous auditing features areavailable through the persistence of records of transaction boundary.The transaction boundaries can be detected using metadata regarding theapplication workflow and creates an awareness to where the transactionis within the workflow.

FIG. 2 illustrates a set of components that may be used to createautomated transaction records according to one or more embodiments ofthe present technology. As illustrated in FIG. 2, client device 210 canrun one or more applications 220 (e.g., customized enterpriseapplications, word processing applications, e-mail applications,spreadsheet applications, etc.) that can store electronic records in acloud-based service 230. Service 230 can be representative of anyservice providing shared access to cloud-based or centralizedapplications, communication, content, and centralized storage. Service230 can include an automated transaction engine that is capable ofseamlessly saving client activity in the background in a transient state(AUTOSAVE).

As shown in FIG. 2, a user can be creating transaction 240 onapplication 220. To facilitate transaction creation and editing,application 220 can include a variety of functionality including GUIs(graphical user interface) running on client device 210, e.g., a PC,mobile phone device, a Web server, or other application servers. Suchsystems may employ one or more virtual machines, containers, or anyother type of virtual computing resource. As a user interacts withapplication 220, activity snapshots 250 can be created representative ofrecent activity associated with transaction 240. Activity snapshots 250can be transmitted to cloud-based service 230 that includes an automatedrecovery engine.

The automated recovery engine can include various components such as,but not limited to recovery engine 231, transaction engine 232, businesslogic 233, audit engine 234, and boundary detector 235. Each of thesecomponents or modules can be embodied as special-purpose hardware (e.g.,one or more ASICS, PLDs, FPGAs, or the like), or as programmablecircuitry (e.g., one or more microprocessors, microcontrollers, or thelike) appropriately programmed with software and/or firmware, or as acombination of special purpose hardware and programmable circuitry.Other embodiments of the present technology may include some, all, ornone of these modules and components along with other modules,applications, and/or components. Still yet, some embodiments mayincorporate two or more of these modules and components into a singlemodule and/or associate a portion of the functionality of one or more ofthese modules with a different module.

While not shown in FIG. 2, some embodiments may include memory that canbe any device, mechanism, or populated data structure used for storinginformation. In accordance with some embodiments of the presenttechnology, the memory can encompass any type of, but is not limited to,volatile memory, nonvolatile memory and dynamic memory. For example, thememory can be random access memory, memory storage devices, opticalmemory devices, media magnetic media, magnetic tapes, hard drives,SDRAM, RDRAM, DDR RAM, erasable programmable read-only memories(EPROMs), electrically erasable programmable read-only memories(EEPROMs), compact disks, DVDs, and/or the like. In accordance with someembodiments, the memory may include one or more disk drives, flashdrives, one or more databases, one or more tables, one or more files,local cache memories, processor cache memories, relational databases,flat databases, and/or the like. In addition, those of ordinary skill inthe art will appreciate many additional devices and techniques forstoring information which can be used as memory.

Moreover, the memory may be used to store instructions for running oneor more applications or modules on one or more processor(s) (not shown).For example, the memory could be used in one or more embodiments tohouse all or some of the instructions needed to execute thefunctionality of recovery engine 231, transaction engine 232, businesslogic 233, audit engine 234, and/or boundary detector 235. As activitysnapshots 250A-250N are received, the automated transaction engine canmonitor, track, and/or record the snapshots. The automated transactionengine provides a unified transaction engine 232 that links technicaltransaction states and business transaction states using business logic233. The number of automated transaction engines may dynamically scale,expand or contract based on volume, timing, and the like.

The transactions monitored by the automated transaction engine caninclude anything that touches data or involves some type of businesstransaction. In some embodiments, the automated transaction engine canlink technical transaction states (e.g., data access) with businesstransaction states (e.g., workflow). In some embodiments, thetransactions and user interactions with the applications are tracked andcan be restored within an application as needed using recovery engine231. This can provide not only auto save type features to eachapplication, whether specified by the domain expert or not while usingthe application design tool. In addition, this type of tracking can beused for versioning and rolling back data. Still yet, since alltransactions from one or more applications can be monitored and/orrecorded by the automated transaction engine, the automated transactionengine can create logs for various types of audits with audit engine234.

In some embodiments, the automated transaction engine can identify stepswithin the workflow and accordingly tag and associate the identifiedworkflow step as part of the transaction data. For example, as if thetransaction includes an order placement, the automated transactionengine can monitor the order placement though a lifecycle (e.g.,pending, approved, shipped, error, etc.). Using boundary detector 235,automated transaction engine can determine different boundaries (e.g.,beginning, end, etc.) of a transaction. Using transaction engine 232,business logic 233, and/or boundary detector 235, service 230 can createand store transient states (e.g., shadow entries) with a transaction. Inaddition, to automated capture of the transient states, a user mayrequest that a restore or replay point be created. Upon receiving thisrequest, service 230 can create restore or replay points. In someembodiments, the transient states created before or after the requestcan be added to the replay point and processed to show the editingactivity during replay mode on the client device.

FIG. 3 illustrates logical components of an automated transaction engineaccording to various embodiments of the present technology. Asillustrated in FIG. 3, the automated transaction engine can trackpending transactions 310, provide undo audits 320, associate thetransactions with workflow 330 or other business data, and track clientsessions. The automated transaction engine provides an expandedtransaction boundary to include more than just a click and save. Inaccordance with various embodiments, the automated transaction enginecan capture explicit and implicit activity to create the transaction.For example, a large complex sales order can require a user to enter orcreate hundreds or thousands of lines.

Traditionally, servers can track everything in the memory of the server.When the user clicks save, the system talks to the database andtransfers a record from the memory to the database. With largetransactions (e.g., sales orders, inventory, etc.), the system cannottransfer the record in a single chunk. By sending multiple transientsnapshots or creating shadow transactions, the system will be able tocontinually update, record, or at least track the record even withoutuser requesting it be saved. Once a user requests the activity be savedor a boundary is automatically detected, the transient snapshots,states, or shadow transactions can be used to create the permanentrecord. In some cases, the activity snapshots may only persist untilexpiration, are expressly deleted after events (e.g., manual saves),etc.

FIG. 4 is a flowchart illustrating a set of operations 400 for restoringa transaction record according to one or more embodiments of the presenttechnology. As illustrated in FIG. 4, creation operation 410 allows auser to create a new transaction record (e.g., a sales record) orcontinue editing an existing transaction record via an application on aclient device. Determination operation 420 can determine whether a userhas specifically requested that the current state be saved (e.g.,request to create a replay point or a restore point). When determinationoperation 420 determines that a specific request has not been made,determination operation 420 branches to monitoring operation 430 whichmonitors for changes to the transaction and/or any activity within theapplication.

As changes are identified by monitoring operation 430, recordationoperation 440 creates a transient transactional record identifying thechanges and/or interactions made by the user within the application.These transient transactional records may only identify changes to thetransaction record that have occurred since the previous transientrecord was sent. As such, these transient transactional records aretypically small and can be efficiently communicated to a server whichcan stored them in a database. These small frequent communications withthe server regarding the current state create a unique conversation orcommunication protocol between the client session and the server.

These transactional records can be assigned an automated transactionidentifier that includes at least a common portion to associate thetransient transactional records with the transaction. The automatedtransaction identifier may also be used to quickly identify that therecord is a shadow of a larger transaction. The record may also includea status indicator identifying whether the record has an autosavepending or has been recovered, a table driver identifier, a useridentifier, a time stamp, a zone identifier, sequence number, data forthe driver, operational activity (e.g., update, delete, insert), and thelike. The record can be persisted with recordation operation 440. Duringthis time, the user may have made additional changes which can bedetected by monitoring operation 430 creating a loop of activitydetection and record creation.

When determination operation 420 determines that a specific request hasbeen made, determination operation 420 branches to identificationoperation 450 which identifies some or all of the transient recordsassociated with the current client session. For example, if a previousrestore or replay point is available, then identification operation 450may only retrieve transient records that are dated/time stamped afterthe previous restore point. By processing the transient records, andprevious restore point if available, creation operation 460 can create anew restore point by reconciling the transient records. For example, auser may add text and then delete the same text. As such, thereconciliation process identifies that the text was later added and thendeleted and should not be present in the restore point. Creationoperation 460 can then branch to determination operation 420 and/ormonitoring operation 430.

Restoration determination operation 470 can determine when a restorationor replay has been requested. This request may be generated by the user,client device, application, or other system. For example, when a failurehas occurred a request to restore may be automatically generated. Whenrestoration determination operation 470 determines that no request hasbeen received, restoration determination operation 470 branches back tomonitoring operation 430. When restoration determination operation 470determines that a request has been made, restoration determinationoperation 470 branches to restoration operation 480 where client sessionis restored.

In some embodiments, restoration operation 480 can identify thetransaction on the client device and retrieve the latest full saveinitiated by the user. Restoration operation 480 can then retrieve theseries of shadow or transient transactional records that wereautomatically created by the system. This can be done, for example, byusing the timestamps in the record to retrieve and/or sort the shadowtransactions that have occurred since the full save. From the fulltransaction each addition, deletion or modification identified in theshadow transactions can be processed and entered. In accordance withvarious embodiments, restoration operation 480 can be done on the clientdevice or on a sever.

FIG. 5 is a flowchart illustrating a set of operations 500 for creatingan audit record according to one or more embodiments of the presenttechnology. As illustrated in FIG. 5, initiation operation 510 initiatesa transaction monitoring processes within the automated transactionengine. Recordation operation 520 captures activity (e.g., additions,deletions, changes, etc.) to a transactional record. Creation operation530 creates snapshots of transient activity (e.g., shadow transactionalrecords, incremental transient records identifying only changes fromsince previous snapshots, etc.) where the user has not requested thecurrent state be saved. Creation operation 530 can result from varioustriggers such as expiration of timers, volume of changes, particularuser activity, particular sets of changes, logical transactionboundaries, metadata defined trigger points, boundary detection (e.g.,change screen), and the like. Once created, transmission operation 540can transmit the activity record from a client device to a cloud-basedautomated transaction engine.

Once the activity record is received at the automated transactionengine, linking operation 550 can link the transient activity record toa transaction. Determination operation 560 can determine if atransaction boundary has been reached. When determination operation 560determines that no transactional boundary has been reach, determinationoperation 560 branches to recordation operation 520 where additionalactivity is captured. When determination operation 560 determines that atransactional boundary has been reach, determination operation 560branches to audit creation operation 570 where an audit record iscreated identifying transient activity as well as requested transactionrecords.

FIG. 6 is a sequence diagram illustrating an example of communicationsbetween various components of a system with an automated transactionengine according to various embodiments of the present technology. Asillustrated in FIG. 6, client device 610 can launch application 620which allows user to create and/or modify transactional records.Application 620 can be hosted in the cloud (e.g., on one or moreservers) or pushed to client devices 610 for access by a user. As a userinteracts with application 620, activity is reported to automatedtransaction engine 630 which can persist the activity within theapplication. As a result, if application 620 crashes, the hostingcomputer loses power, or some other event occurs, then application 620can request state data from automated transaction engine 630. Inresponse, automated transaction engine 650 can transmit the state datato application 620 which can return application 620 to the last knowstate before the failure occurred.

As a result, various embodiments of automated transaction engine 650provide one or more of the following benefits: 1) work can never belost—even if a browser client crashes—work is seamlessly saved in thebackground in a transient state (AUTOSAVE); 2) all business data errorsare tracked and the transactions in error can be corrected andresubmitted; 3) any system errors are also tracked and can be similarlyrecovered—regardless of availability of two phase commit by underlyingengine processing transaction; 4) workflow is integrated by managing thestate of any transactions; 5) other business state (posted/unposted) canbe similarly tracked (as part of the workflow system); 6) an audit trailis retained for all state changes; and/or 7) Given the appropriatepermissions any transaction or change can be undone or rolled back.

Exemplary Computer System Overview

FIG. 7 illustrates computing system 710, which is representative of anysystem or collection of systems in which the various applications,services, scenarios, and processes disclosed herein may be implemented.For example, computing system 710 may include server computers, bladeservers, rack servers, and any other type of computing system (orcollection thereof) suitable for carrying out the enhanced collaborationoperations described herein. Such systems may employ one or more virtualmachines, containers, or any other type of virtual computing resource inthe context of supporting enhanced group collaboration.

Computing system 710 may be implemented as a single apparatus, system,or device or may be implemented in a distributed manner as multipleapparatuses, systems, or devices. Computing system 710 includes, but isnot limited to, processing system 720, storage system 730, software 740,applications 750, communication interface system 760, and user interfacesystem 770. Processing system 720 is operatively coupled with storagesystem 730, communication interface system 760, and an optional userinterface system 770.

Processing system 720 loads and executes software 740 from storagesystem 730. When executed by processing system 720 for deployment ofscope-based certificates in multi-tenant cloud-based content andcollaboration environments, software 740 directs processing system 720to operate as described herein for at least the various processes,operational scenarios, and sequences discussed in the foregoingimplementations. Computing system 710 may optionally include additionaldevices, features, or functionality not discussed for purposes ofbrevity.

Referring still to FIG. 7, processing system 720 may comprise amicro-processor and other circuitry that retrieves and executes software740 from storage system 730. Processing system 720 may be implementedwithin a single processing device, but may also be distributed acrossmultiple processing devices or sub-systems that cooperate in executingprogram instructions. Examples of processing system 720 include generalpurpose central processing units, application specific processors, andlogic devices, as well as any other type of processing device,combinations, or variations thereof.

Storage system 730 may comprise any computer readable storage mediareadable by processing system 720 and capable of storing software 740.Storage system 730 may include volatile and nonvolatile, removable andnon-removable media implemented in any method or technology for storageof information, such as computer readable instructions, data structures,program modules, or other data. Examples of storage media include randomaccess memory, read only memory, magnetic disks, optical disks, flashmemory, virtual memory and non-virtual memory, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other suitable storage media. In no case is the computer readablestorage media a propagated signal.

In addition to computer readable storage media, in some implementationsstorage system 730 may also include computer readable communicationmedia over which at least some of software 740 may be communicatedinternally or externally. Storage system 730 may be implemented as asingle storage device, but may also be implemented across multiplestorage devices or sub-systems co-located or distributed relative toeach other. Storage system 730 may comprise additional elements, such asa controller, capable of communicating with processing system 720 orpossibly other systems.

Software 740 may be implemented in program instructions and among otherfunctions may, when executed by processing system 720, direct processingsystem 720 to operate as described with respect to the variousoperational scenarios, sequences, and processes illustrated herein. Forexample, software 740 may include program instructions for directing thesystem to perform the processes described above.

In particular, the program instructions may include various componentsor modules that cooperate or otherwise interact to carry out the variousprocesses and operational scenarios described herein. The variouscomponents or modules may be embodied in compiled or interpretedinstructions, or in some other variation or combination of instructions.The various components or modules may be executed in a synchronous orasynchronous manner, serially or in parallel, in a single threadedenvironment or multi-threaded, or in accordance with any other suitableexecution paradigm, variation, or combination thereof. Software 740 mayinclude additional processes, programs, or components, such as operatingsystem software, virtual machine software, or application software.Software 740 may also comprise firmware or some other form ofmachine-readable processing instructions executable by processing system720.

In general, software 740 may, when loaded into processing system 720 andexecuted, transform a suitable apparatus, system, or device (of whichcomputing system 710 is representative) overall from a general-purposecomputing system into a special-purpose computing system. Indeed,encoding software on storage system 730 may transform the physicalstructure of storage system 730. The specific transformation of thephysical structure may depend on various factors in differentimplementations of this description. Examples of such factors mayinclude, but are not limited to, the technology used to implement thestorage media of storage system 730 and whether the computer-storagemedia are characterized as primary or secondary storage, as well asother factors.

For example, if the computer readable storage media are implemented assemiconductor-based memory, software 740 may transform the physicalstate of the semiconductor memory when the program instructions areencoded therein, such as by transforming the state of transistors,capacitors, or other discrete circuit elements constituting thesemiconductor memory. A similar transformation may occur with respect tomagnetic or optical media. Other transformations of physical media arepossible without departing from the scope of the present description,with the foregoing examples provided only to facilitate the presentdiscussion.

Communication interface system 760 may include communication connectionsand devices that allow for communication with other computing systems(not shown) over communication networks (not shown). Examples ofconnections and devices that together allow for inter-systemcommunication may include network interface cards, antennas, poweramplifiers, RF circuitry, transceivers, and other communicationcircuitry. The connections and devices may communicate overcommunication media to exchange communications with other computingsystems or networks of systems, such as metal, glass, air, or any othersuitable communication media. The aforementioned media, connections, anddevices are well known and need not be discussed at length here.

User interface system 770 may include a keyboard, a mouse, a voice inputdevice, a touch input device for receiving a touch gesture from a user,a motion input device for detecting non-touch gestures and other motionsby a user, and other comparable input devices and associated processingelements capable of receiving user input from a user. Output devicessuch as a display, speakers, haptic devices, and other types of outputdevices may also be included in user interface system 770. In somecases, the input and output devices may be combined in a single device,such as a display capable of displaying images and receiving touchgestures. The aforementioned user input and output devices are wellknown in the art and need not be discussed at length here. In somecases, the user interface system 770 may be omitted when the computingsystem 710 is implemented as one or more server computers such as, forexample, blade servers, rack servers, or any other type of computingserver system (or collection thereof).

User interface system 770 may also include associated user interfacesoftware executable by processing system 720 in support of the varioususer input and output devices discussed above. Separately or inconjunction with each other and other hardware and software elements,the user interface software and user interface devices may support agraphical user interface, a natural user interface, or any other type ofuser interface, in which a user interface to a productivity applicationmay be presented.

Communication between computing system 710 and other computing systems(not shown), may occur over a communication network or networks and inaccordance with various communication protocols, combinations ofprotocols, or variations thereof. Examples include intranets, internets,the Internet, local area networks, wide area networks, wirelessnetworks, wired networks, virtual networks, software defined networks,data center buses, computing backplanes, or any other type of network,combination of network, or variation thereof. The aforementionedcommunication networks and protocols are well known and need not bediscussed at length here. In any of the aforementioned examples in whichdata, content, or any other type of information is exchanged, theexchange of information may occur in accordance with any of a variety ofwell-known data transfer protocols.

CONCLUSION

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense, as opposed to anexclusive or exhaustive sense; that is to say, in the sense of“including, but not limited to.” As used herein, the terms “connected,”“coupled,” or any variant thereof means any connection or coupling,either direct or indirect, between two or more elements; the coupling orconnection between the elements can be physical, logical, or acombination thereof. Additionally, the words “herein,” “above,” “below,”and words of similar import, when used in this application, refer tothis application as a whole and not to any particular portions of thisapplication. Where the context permits, words in the above DetailedDescription using the singular or plural number may also include theplural or singular number, respectively. The word “or,” in reference toa list of two or more items, covers all of the following interpretationsof the word: any of the items in the list, all of the items in the list,and any combination of the items in the list.

The above Detailed Description of examples of the technology is notintended to be exhaustive or to limit the technology to the precise formdisclosed above. While specific examples for the technology aredescribed above for illustrative purposes, various equivalentmodifications are possible within the scope of the technology, as thoseskilled in the relevant art will recognize. For example, while processesor blocks are presented in a given order, alternative implementationsmay perform routines having steps, or employ systems having blocks, in adifferent order, and some processes or blocks may be deleted, moved,added, subdivided, combined, and/or modified to provide alternative orsubcombinations. Each of these processes or blocks may be implemented ina variety of different ways. Also, while processes or blocks are attimes shown as being performed in series, these processes or blocks mayinstead be performed or implemented in parallel, or may be performed atdifferent times. Further any specific numbers noted herein are onlyexamples: alternative implementations may employ differing values orranges.

The teachings of the technology provided herein can be applied to othersystems, not necessarily the system described above. The elements andacts of the various examples described above can be combined to providefurther implementations of the technology. Some alternativeimplementations of the technology may include not only additionalelements to those implementations noted above, but also may includefewer elements.

These and other changes can be made to the technology in light of theabove Detailed Description. While the above description describescertain examples of the technology, and describes the best modecontemplated, no matter how detailed the above appears in text, thetechnology can be practiced in many ways. Details of the system may varyconsiderably in its specific implementation, while still beingencompassed by the technology disclosed herein. As noted above,particular terminology used when describing certain features or aspectsof the technology should not be taken to imply that the terminology isbeing redefined herein to be restricted to any specific characteristics,features, or aspects of the technology with which that terminology isassociated. In general, the terms used in the following claims shouldnot be construed to limit the technology to the specific examplesdisclosed in the specification, unless the above Detailed Descriptionsection explicitly defines such terms. Accordingly, the actual scope ofthe technology encompasses not only the disclosed examples, but also allequivalent ways of practicing or implementing the technology under theclaims.

To reduce the number of claims, certain aspects of the technology arepresented below in certain claim forms, but the applicant contemplatesthe various aspects of the technology in any number of claim forms. Forexample, while only one aspect of the technology is recited as acomputer-readable medium claim, other aspects may likewise be embodiedas a computer-readable medium claim, or in other forms, such as beingembodied in a means-plus-function claim. Any claims intended to betreated under 35 U.S.C. § 112(f) will begin with the words “means for”,but use of the term “for” in any other context is not intended to invoketreatment under 35 U.S.C. § 112(f). Accordingly, the applicant reservesthe right to pursue additional claims after filing this application topursue such additional claim forms, in either this application or in acontinuing application.

What is claimed is:
 1. A system comprising: a processor; a memory; acommunications component configured to: receive activity snapshotsidentifying changes to a transactional entry being modified in anapplication running on a client device, wherein the activity snapshotsare automatically created in response to triggering events; and atransaction engine configured to create transient records that link theactivity snapshots received from the client device to a transaction,wherein the transaction engine uses business logic to associate anapplication workflow state to each of the activity snapshots, andwherein the transaction engine assigns a transaction identifier to eachof the activity snapshots; a database to store the transient records. 2.The system of claim 1, further comprising a recovery engine to return,in response to a request from the application running on the clientdevice, a series of transient records representing a series of changesto the transactional entry to return the transactional entry from acurrent state to a previous state.
 3. The system of claim 1, wherein theactivity snapshots only identify changes to the transactional entrysince a previous activity snapshot.
 4. The system of claim 3, whereintriggering events include expiration of a time interval, logicaltransaction boundaries, metadata defined trigger points, or metadataboundaries.
 5. The system of claim 1, further comprising an audit engineconfigured to: access the transient records stored in the database; andcreate, based on the business logic, an audit trail identifying workflowactivity.
 6. The system of claim 1, further comprising a metadata-drivenboundary detector to analyze the transient records for boundariesidentified by the business logic and, in response to detection of any ofthe boundaries, automatically create persistent records within thedatabase.
 7. The system of claim 6, wherein boundary detector createsthe persistent records based on the transient records and then removesthe transient records from the database.
 8. A method comprising:receiving, from an application accessed on a client device, activitysnapshots identifying changes to a transaction being modified in theapplication, wherein the activity snapshots are automatically created inresponse to triggering events; and wherein the activity snapshotsidentify only the changes to the transaction that have occurred since aprevious activity snapshot; linking the activity snapshots to anautomated transaction record; wherein linking the activity snapshots tothe automated transaction record includes assigning a transactionidentifier to the activity snapshots; receiving a request to restore thetransaction to a previous state; and processing the activity snapshotsassociated with the automated transaction record to create the previousstate of the transaction.
 9. The method of claim 8, wherein the requestto restore the transaction to the previous state is automaticallygenerated.
 10. The method of claim 8, wherein the activity snapshotsalso identify a user of the application and a client session.
 11. Themethod of claim 8, wherein processing the activity snapshots associatedwith the automated transaction record comprises: identifying a subset oftransactional data that will return the automated transaction record tothe previous state; and transmitting, from a server to the clientdevice, the subset of the transactional data to the application.
 12. Themethod of claim 8, wherein the application is one of multipleapplications generated by a cloud-based software platform and whereinthe cloud-based software platform provides a set of common services toeach of the multiple applications.
 13. The method of claim 12, whereinthe set of common services include administrative service, applicationprograming interfaces, and security services.
 14. The method of claim 8,wherein the transaction is being created in a client session hosted byone or more servers in a stateless manner.
 15. The method of claim 8,further comprising identifying a set of business rules associated withthe transaction.
 16. The method of claim 15, wherein linking theactivity snapshots to the automated transaction record includesassociating a state of workflow specified according to a set of businessrules.
 17. A computer-readable medium, excluding transitory signals,storing instructions that when executed by one or more processors causea machine to: monitor user interactions entered via an applicationrunning on a client device; generate activity snapshots identifyingchanges to a transaction being modified in the application, wherein theactivity snapshots are automatically created in response to triggeringevents; and wherein the activity snapshots identify only the changes tothe transaction that have occurred since a previous activity snapshot;link the activity snapshots to an automated transaction record byassigning a transaction identifier to the activity snapshots; receive arequest to restore the transaction to a previous state; and process theactivity snapshots associated with the automated transaction record tocreate the previous state of the transaction.
 18. The computer-readablemedium of claim 17, wherein the instructions when executed by the one ormore processors further cause the machine to monitor the transaction andidentify a transaction boundary.
 19. The computer-readable medium ofclaim 18, wherein the triggering events include expiration of a timeinterval, logical transaction boundaries, metadata defined triggerpoints, or metadata boundaries.
 20. The computer-readable medium ofclaim 17, wherein the activity snapshots also identify a user of theapplication and a client session.